1. Field of the Invention
The present invention relates generally to a computer configuration device and, more particularly, to a tool for providing price/performance normalization in determining an optimal computer configuration depending upon the user""s specific applications.
2. Description of the Related Art
The original computers were very complex devices that required skilled technicians and scientists to operate. When a new device, such as a printer, was added to the computer, special software and hardware needed to be developed specifically for the new device. With the advent of personal computers, it became impractical to require users to develop new software and hardware whenever new hardware was added.
Computer components eventually became standardized, and one of the important pieces of the puzzle was the Disk Operating System, or DOS. Originally DOS only supported a small number of devices such as printers, floppy drives, and hard disk drives. In addition, DOS was severely limited in the number of different computer configurations and components such as memory and peripherals that could be supported.
One advance in the computer arts was the arrival of xe2x80x9cplug-and-playxe2x80x9d architecture. Plug-and play means that a device can be added to a system without significant setup. This and other tools were the result of the standardization of interfaces which enables many devices to be easily configured to work together.
Today, the typical consumer and business user is presented with an astonishing number of choices with respect to the configuration of a new computer. A computer can be tailored to the particular needs of every user, from a multi-national corporation with immense database requirements to an individual who only desires to log into the Internet. There are computers specialized to perform such tasks as bulk memory storage, communications, and game playing. Depending upon a user""s needs, a computer can be configured with anywhere from 16 megabytes to hundreds of megabytes of random access memory (RAM). Static storage such as hard disk drives can vary in capacity from gigabytes (109 bytes) to terabytes (1012 bytes) of data, each arranged in any one of a large number of configurations. Large amounts of RAM and static storage, however, cost proportionally more money. As a result, there is usually a tradeoff between price and performance.
The number of possible devices that can be added to any particular system has also grown. Computers now routinely come with devices that were unavailable even a few decades ago, such as speakers, CD-ROM drives, and fax modems. In addition, a user can add a large number of additional components such as tape drives, network cards, and specialized, game playing devices such as a joy stick. The number of possible choices for a computer system configuration is multiplied by the number of manufacturers that produce each component producing perhaps millions of possible systems.
Using a device implemented according to the invention, a framework for a computer system configuration device (xe2x80x9cframeworkxe2x80x9d) provides a user interface and functionality common to a number of computer system configuration devices (xe2x80x9csizersxe2x80x9d) that are tailored for specific applications. A sizer collects user data requirements, navigates through possible computer hardware configurations, estimates performance of specific configurations, and provides a recommended configuration to the framework for presentation to an end-user.
The sizer will typically execute in the Windows 95 and Windows NT native environment and is extendible to other environments such as SCO UNIX. The framework architecture can also be extended to support web hosted clients. The framework also supports sizers for multiple operating systems, which means that, even though the sizer is typically implemented on Windows 95 or Windows NT, it could be run in other environments such as SCO UNIX or any such variant. The framework supports multiple product sizers, all of which may be executed serially. The framework can be extended to sizing multiple products on a single server.
A framework can support registration of sizers on the fly, allowing them to provide their credentials, authenticate their identity, and register in the framework""s sizer registry. The framework provides front end-user interface management services like navigation, report generation, as well as middle level services like hardware configuration and constraint management. In addition, the framework provides back end services like data persistence. In short, the framework abstracts common sizer functionality and allows for creating a product sizer with minimal effort.
More specifically, the framework preferably supports a plug and play architecture, in essence allowing individual sizers to be plugged into the framework easily. The framework allows sizers to be dynamically attached to the framework through a xe2x80x9cregistrationxe2x80x9d mechanism. To add a sizer to the framework, a xe2x80x9cOpen filexe2x80x9d like dialog is presented and selecting a sizer effectively sends a request to the framework for registration. To accomplish this the framework requests identification and resource requirements from the individual sizers, and the sizers provide the relevant information. The framework fills its main panel of information about the sizers characteristics by issuing a series of queries, in effect making calls to known entry points in the sizers"" dynamic linked libraries (DLL).
The framework provides user interface management services providing a common look and feel for all sizers supported by it. The framework provides navigation services that allow for navigating between pages. This means that the framework is responsible for navigating among screens generated by the framework, a sizer, and possibly multiple sizers. The same set of facilities is provided for any xe2x80x9cutility,xe2x80x9d such as a data management utility, that is tacked onto the framework.
The framework can support launching secondary utilities by calling single entry point DLL""s. This is the preferred way of calling utilities, to obviate the need to manage secondary window creations when making system calls. If the secondary utility requires a windowing interface, then it will export entry points identical to the product sizer""s. Utilities to store and maintain sizer data tables, specifically server configurations and data models, are provided.
The framework also has a dialog that presents information about sizer characteristics, availability choices for individual sizers, and server recommendations. A sizer dialog is typically sandwiched between framework dialogs.
The framework generates user-requested reports specific to system recommendations and attendant workload characteristics specified by the user. The framework also, upon request, prints the reports.
The framework supports multiple levels of availability. Availability is a level of acceptable continual access in the ultimately configured system""s data and resources. Availability considerations invariably affect the performance and configuration of every solution. Two factors that affect availability, performance, and possible configuration solutions are fault tolerance and a server recovery. Fault tolerance addresses the effects of single disk failures or, in other words, how much time is required to recover from a failure and how much work is lost as a result of a failure.
The information on which processors can be recommended by a sizer is extracted from the sizer by the framework and a subset of the processors is communicated to the user. The framework will support all relevant processor subsystems known at the time of release, however an individual sizer may choose to support only a subset of the available processors. The framework will need to know of the supported subset so that it may present it to the user as well as for doing configuration constraint management.
The processor subsystem is composed of the architecture or server type, the processor, and the processor quantity. There can be many processor subsystems defined for a server, but for sizing purposes, a server roughly corresponds to a processor architecture.
Using the workload specification and availability selections, a set of recommended hardware components is determined and presented to the user. The recommended components can include, but are not limited to, the server processor selections, the number of processors recommended, the recommended memory, the network interface card (NIC), and the recommended disk quantities and capacities. Recommendations may include disks with varying capacities. The recommended hardware components are configurable into a valid solution; for instance, a server that supports the processor selection also supports the recommended memory and quantity of disk drives.
The framework exposes to the sizer a mechanism to extract information about individual processor subsystems and, based on the information, lets the sizer xe2x80x9cselect,xe2x80x9d by way of a public protocol (public methods) the processor, number of processors, amount of RAM, drives, and controllers, and disk array information. The framework maintains a list of available processor subsystems and attributes and allows the sizer to xe2x80x9cpagexe2x80x9d through the available systems to find the best fit.
The xe2x80x9cselectedxe2x80x9d configuration, which includes processor, processor speed, cache size, number of processors, controllers, and disk array information is communicated to the user. The disk array information includes: the description of the array contents provided by the sizer), the recommended drive capacity and number of drives, and whether the drives have to be added in pairs as in a RAID 1 architecture. The framework, based upon the information provided by the product sizer, recommends the drive capacity and quantity for each drive, the number of drives recommended to support the I/O load, and the storage required for each. The RAID level is displayed and/or reported. The framework also computes and displays a relative price for the completed configuration.